My vision for what these case studies would look like is closer to something like... identify X pattern out in the wild, summarize what you think is good about it, summarize what you think needs improvement.

What you provided is an active engagement from Mutual contributors towards a project that is being built in real time. I think this is definitely something we should engage in and it seems like there are great opportunities out there already, like what Sirsu suggested. My only concern is that we don't have anything written in place just yet to conduct these design audits against.

My vision for what these case studies would look like is closer to something like... identify X pattern out in the wild, summarize what you think is good about it, summarize what you think needs improvement.

we should come up with a clearer definition of "case study." imo the scope of a "case" is an entire project, not just one pattern, but I actually agree having more focused dives into specific patterns might be the ideal way to structure this type of thing (also makes it easier for people to contribute)

imo having full project reviews is still a great resource because u can rlly get holistic with it. maybe we need diff categories?

@losingmyego what u think?

thanks for the link @salieflewis 👁️ Agree about the definition of "case studies" needing to be more concrete. I Find myself wanting to know:

• Who are case studies for?
• How will they use them?
• What do they contain?

The definition I was imagining based on the previous Mutual calls was something like:

"Case studies are for engineers & designers to reference when building with crypto. Case studies aim to make a case for a specific pattern being the "best practice. They contain references to good patterns and bad patterns to make that point. They may also contain links to projects/solutions that Mutual endorses."

I'm imagining a system where patterns are captured & then used to compose case studies. In the act of composing a case study, someone might choose to identify and submit new patterns, or browse already submitted ones. Someone may stumble on a new project with novel patterns, and choose to capture them - as new patterns and technology emerges we can expect that the results of a case study might be challenged. I'm not sure what the threshold for a case study should be in order to be accepted as a "best practice". Some level of endorsement from the community might make sense. It might also be a good idea to capture dissenting opinions in that case.

thanks for the link @salieflewis 👁️ Agree about the definition of "case studies" needing to be more concrete. I Find myself wanting to know:

• Who are case studies for?
• How will they use them?
• What do they contain?

The definition I was imagining based on the previous Mutual calls was something like:

"Case studies are for engineers & designers to reference when building with crypto. Case studies aim to make a case for a specific pattern being the "best practice. They contain references to good patterns and bad patterns to make that point. They may also contain links to projects/solutions that Mutual endorses."

I'm imagining a system where patterns are captured & then used to compose case studies. In the act of composing a case study, someone might choose to identify and submit new patterns, or browse already submitted ones. Someone may stumble on a new project with novel patterns, and choose to capture them - as new patterns and technology emerges we can expect that the results of a case study might be challenged. I'm not sure what the threshold for a case study should be in order to be accepted as a "best practice". Some level of endorsement from the community might make sense. It might also be a good idea to capture dissenting opinions in that case.

Agree with you completely on all of this and am definitely aligned with your definition of case study. From last I spoke to @losingmyego I know that they were adamant about articulating Mutual heuristics before moving into a concrete definition of what comprises a case study. Hopefully this doesn't feel like a blocker. Would be interested in speaking with both you and Neesh about how these heuristics are getting surfaced!

Thanks for the patience @0xTranqui @salieflewis @tlrmlr ,
have been observing this convo and having another with Alanah from FuturePrimitive. My thinking on the case studies has evolved into realizing a few things :

• If we want to record patterns, we need to do more than describe them — case study submissions will require the submitter to fill out a User Experience Flowchart.
• These flowcharts are going to be the most important part of the case study, other designers and engineers will understand so much more about an interaction from a visual flowchart than reading a paragraph.
• The text/form part of the case studies will mostly be used for Labeling the case study into the right categories and explaining any Dependencies, environmental factors, or weird edge case stuff.

My initial thoughts in diagram form : (FigJam)

What this means

• The Heuristics / Design Principles will heavily influence the "Set of Questions to Answer" part of the Case Study form.
• We need to make some decisions on what we consider on-chain transactions vs. off-chain transactions
• We need to list out as many tokenomic flows as we can think of (mint + burn, mint + stake, stake + mint + burn, etc etc) and create labels for them in the database
• Us creating boiler plate FigJam User Experience Flow diagrams with rules on what to do and how to style if you want to change them.
• Starting to create boiller plate templates for as many patterns as we can

Questions for @salieflewis

• How soon can we create a system of Github -> Website Database?
• How does it work if we want to allow submitters to create a new category / tag / label outside ones we have predefined?